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ABSTRACT 


The objective of this thesis is to conduct a thorough analysis of the documentation 
and policy that currently exists within the Department of Defense (DoD) framework. 
There are numerous gaps within this documentation pertaining to Human Systems 
Integration (HSI) in the Integrated Defense Acquisition, Technology, and Logistics 
(IDAT&L) Life Cycle. The U.S. Navy currently implements HSI at different stages 
throughout the Life Cycle, but it lacks continuity throughout the entire process. A 
detailed analysis of the IDAT&L framework can potentially aid in redefining how the 
Navy should address HSI, by identifying areas where HSI policies and guidelines should 
exist, but currently do not (i.e., gaps), and then proposing ways to close those gaps and 
streamline the HSI process as a whole throughout the Navy. This thesis suggests a 
potential, strengthened framework for HSI in the Navy, based on the information and 
findings gathered from not only the current framework, but also current Navy policies. 
The outcome of this thesis is to improve the entire HSI process throughout the Navy and 


help ensure that HSI is used effectively throughout the acquisition process. 
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EXECUTIVE SUMMARY 


The objective of this thesis is to conduct a thorough analysis of the documentation 
and policy that currently exists within the Department of Defense (DoD) framework. 
There are numerous gaps within this documentation pertaining to Human Systems 
Integration (HSI) in the Integrated Defense Acquisition, Technology, and Logistics 
(IDAT&L) Life Cycle. The U.S. Navy currently implements HSI at different stages 
throughout the Life Cycle, but it lacks continuity throughout the entire process. A 
detailed analysis of the IDAT&L framework can potentially aid in redefining how the 
Navy should address HSI, identifying areas where HSI policies and guidelines should 
exist, but currently do not (i.e., gaps), and then proposing ways to close those gaps and 
streamline the HSI process as a whole throughout the Navy. 

The acquisition process contains a thorough structure from the moment a need for 
the military is identified to the moment that the need is retired and disposed. This process 
guides the acquisition community through the important steps to obtain a system that will 
meet the standards that are required. Within each phase of the Life Cycle, the Program 
Manager (PM) is required to meet these standards. Every member of the acquisition 
team, from the user to the engineer, knows what is required during this process of the 
Life Cycle. 

HSI is a growing field that requires complete immersion into the acquisition 
process. As of yet, it has not been fully integrated throughout all of the phases. In order to 
obtain and develop the best system for the military, the acquisition community must gain 
the knowledge of the system and the user. In order to develop the system with the user in 
mind, the acquisition cycle must integrate HSI throughout the entire process. The 
integration of these HSI standards will allow the PM and his/her team to acquire the best 
system to meet the needs of the military. 

The development of a model that would serve as our baseline allowed us to do a 
gap analysis on the policies and documentation within the U.S. Navy’s acquisition 
process. The gap analysis provided us with the gaps between the HSI standards (our 


model) and what the policies and documents say is required. The recommendations are 


XV 


provided to gain knowledge on how the process could be changed in order to obtain the 
best system for the military. This model was developed with the U.S. Navy as the main 
priority, but may also be useful for the other services. 

Based on the comparative analysis of the current HSI policies and procedures 
utilized by the Navy, and the gaps identified in the guidelines and policies reviewed, this 
thesis makes recommendations for a joint framework for a new comprehensive policy 
throughout the IDAT&L Life Cycle Management Process. These recommendations 
intend to improve the efficiency and effectiveness of the acquisition process and the 


further development of HSI. 
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I. INTRODUCTION 


A. PURPOSE 


The objective of this thesis is to analyze the documentation and policy that 
currently exists within the Department of Defense (DoD) framework dealing with the 
Integrated Defense Acquisition, Technology, and Logistics (IDAT&L) Life Cycle 
focusing specifically on how the United States Navy addresses Human Systems 
Integration (HSI). Currently, the Navy implements HSI at different stages throughout the 
Life Cycle. An analysis of the IDAT&L framework can potentially aid in understanding 
how the Navy should address HSI, identifying areas where HSI policies and guidelines 
should exist, but do not (i.e., gaps), and then proposing ways to close those gaps. This 
thesis is a potential strengthened framework for the Navy, based on the information and 
knowledge gathered from not only the current framework, but also from current Navy 


policies. The objective of this thesis is to improve the entire HSI process. 


B. BACKGROUND 


HSI and the Defense acquisition process are inextricably linked. In order to 
understand how the Defense Acquisition System works, it is critical to understand its 
structure and direction. The foundation of the acquisition process lies at the roots of HSI. 
Without a solid footing in one, the other cannot be successful. The Defense Acquisition 


System, by definition, is a 


. Management process by which the Department of Defense acquires 
quality products in a timely manner, at a fair and responsible price, and 
which satisfies user needs with measureable improvements to mission 
capability and operational support. The Defense Acquisition System exists 
to manage the nation’s investments in technologies, programs, and product 
support in such a way so as to achieve the National Security Strategy to 
support not only today’s armed forces, but also the next force and future 
forces beyond that. (Naval Air Systems Command (NAVAIR) Acquisition 
Guide, 2008, p. 6) 


HSI is thought to be a process of incorporating characteristics, capabilities, and 
limitations of humans within the IDAT&L decision-making process. However, no set 
definition has been agreed on by HSI practioners. A leading pioneer in the field of HSI, 
Harold R. Booher, defines HSI in his book, Handbook of Human Systems Integration 
(2003), as: “. . .a comprehensive management and technical program that focuses on the 
integration of human considerations into the systems acquisition process” (p. 5). The 
DoD Handbook on Human _ Engineering Process and __ Procedures, 
MIL-HDBK-46855A, defines HSI as: 

A comprehensive management and technical strategy to ensure that human 

performance, the burden design imposes on manpower, personnel, and 

training (MPT), and safety and health aspects are considered throughout 
system design and development. HSI assists with the total system 
approach by focusing attention on the human part of the total system 
equation and by ensuring that human-related considerations are integrated 


into the system acquisition process. (MIL-HDBK-46855A, Section 5.1.2, 
1999, p. 19) 


The Naval Postgraduate School defines HSI as: 


HSI acknowledges that the human is a critical component of any complex 

system. It is an interdisciplinary approach that makes explicit the 

underlining tradeoffs across the HSI domains, facilitating optimization of 

total system performance. (Miller & Shattuck, 2006, p. 4) 

The National Aeronautics and Space Administration (NASA) defines HSI on their 
NASA Ames HSI Webpage as: 

. an umbrella term for several areas of ‘human factors’ research that 
include human performance, technology design, and human-computer 
interaction. The study of Human Systems Integration at NASA Ames 
Research Center focuses on the need for safe, efficient and cost-effective 
operations, maintenance and training, both in space, in flight and on the 
ground. (NASA Ames HSI Website, 2009) 

As can be seen from the definitions above, HSI practioners do not agree on a 
formal definition of HSI. Given the interdisciplinary nature of this field, arriving on a set 
definition is imperative as a first step in seeing a successful joint IDAT&L framework. 


Ideally, all DoD components should understand and agree on the definition of the field in 


which they are required to work. 


Based on the “reality” that HSI practioners and DoD-related agencies do not agree 
on a common definition, it is not surprising that they do not agree on common domains 
within HSI. The seven domains of HSI are listed in MIL-HDBK-46855A, the DoD 
Handbook on Human Engineering Process and Procedures: Human Factors Engineering, 
Manpower, Personnel, Training, Safety, Health Hazards, and Human Survivability 


(1999). 
Department of Defense Instruction (DoDI) 5000.02, which was revised in 2008, 


. establishes a simplified and flexible management framework for 
translating mission needs and technology opportunities, based on 
approved mission needs and requirements, into stable, affordable, and well 
managed acquisition programs that include weapon systems and 
automated information systems. (DoDI 5000.02, 2008, p. 1) 

This instruction applies to all services within the DoD and defines the domains of HSI as: 
Manpower, Personnel, Training, Human Factors Engineering, Survivability, Habitability, 
Environment, Safety, and Occupational Health (DoDI 5000.02, 2008). Although these 
domains are defined in the above document, each service has redefined domains based on 
their mission requirements. Table 1 shows disparities among the services in the HSI 


domains. Like a common definition, agreeing on domains is essential to a successful joint 


acquisition strategy. 


Table 1. 


Service HSI domains (After: Miller & Shattuck, 2006) 



































NAVY ARMY AIR FORCE MARINE CORPS NASA 
Manpower Manpower Manpower Manpower Manpower 
Personnel Personnel Personnel Personnel Personnel 

Training Training Training Training Training 
Human Factors | Human Factors | Human Factors Human Factors Human Factors/ 
Engineering Engineering Engineering Engineering Human Factors 
Engineering 
Human Soldier Human Human Survivability Survivability 
Survivability Survivability Survivability 
System Safety | System Safety System Safety System Safety System Safety, 
Environmental 
Safety, 
Occupational 
Safety 
Health Hazards | Health Hazards Occupational Health Hazards Health, Medical 
Health Hazards Hazards 
Habitability Habitability Habitability Habitability 
Environment 

















HSI sprang from problems in implementing the IDAT&L Life Cycle Management 
Framework. Although the field of human factors has existed for decades, the 
interdisciplinary field of HSI began to emerge after a 1981 General Accounting Office 
(GAO) report attributed 50% of all military equipment failures to human error 
(GAO, 1981). 

The report confirmed that the effectiveness of U.S. forces could be 

significantly increased through improved weapon system design. Further, 

it stressed the immediate need for the integration of manpower, personnel, 

and training (MPT) considerations into the acquisition process. (Belcher, 

1995, p. 3) 

The recognition of this deficiency led to the birth of two DoD programs: 
Hardware Procurement and Military Manpower (HARDMAN) for the Navy and Military 
and Manpower Integration (MANPRINT) in the Army. These programs were designed to 
improve human performance and equipment reliability, while helping to weed out system 
design flaws. 

In December 1988, the DoD published Directive 5000.53, entitled “Manpower, 
Personnel, Training, and Safety (MPTS) in the Defense Acquisition Process.” This 


document helped establish common MPTS criteria among all services, but was 
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superseded soon after by DoDI 5000.2, “Defense Acquisition Management Policies and 
Procedures,” in February 1991. This new document “mandated that human considerations 
shall be effectively integrated into the design effort for defense systems to improve total 
system performance and reduce ownership costs” (DoD , 2003, p. 43). 

Although the 2003 version of DoDI 5000.2 outlined the requirement for HSI, the 
method of implementation was left to each individual service. Because each service owns 
“HSI,” the term “Human Systems Integration” gets thrown around quite often; however, 
few individuals know how it works and how it should be implemented. With that being 
said, each service has created a unique method for implementing it within the confines of 
that service, but there is still little agreement on what HSI is and how each service should 
implement it in the Acquisition Framework. 

In 2008, the 2003 version of DoDI 5000.2 was replaced with DoDI 5000.02. The 
new 2008 version is similar to the 2003 version, requiring the PM to optimize total 
system performance and minimize the Life Cycle cost of ownership through a “total 
system approach” to acquisition management. Government contractors know that HSI is 
a contractual requirement that must be completed during the design and development 
phases of the acquisition process (Integrated Framework chart, 2005). Usually, HSI is 
initially addressed as a program plan in the Joint Capabilities Integration Development 
System (JCIDS) process. However, its importance extends beyond Milestone B. After 
Milestone B, HSI builds the foundation of the materiel solution required to be in the 
program plan. If a materiel solution is not identified in JCIDS, the Life Cycle ends and 
HSI is not implemented throughout the remainder of the doctrine, organization, training, 
materiel, leadership and education, personnel and facilities (DOTMLPF). Hence, DoDI 
5000.02 does not address the entire Life Cycle in the document; HSI is also not 
addressed, leaving little or no consideration to the total Life Cycle cost of the program. 
Current service policy addressing HSI is limited and differs among the services. The 
vague wording of many of these documents indicates that HSI needs to be done; 
however, it does not provide criteria or guidelines for how to conduct HSI throughout the 
Life Cycle. This lack of information is why it is important that a comprehensive joint 


acquisition policy, which addresses HSI throughout the Life Cycle, be created and 


implemented. This thesis makes recommendations for a joint framework for a new 


comprehensive policy throughout the IDAT&L Life Cycle Management Process. 


C. RESEARCH OBJECTIVES 


The objectives of this thesis are to: 


Conduct a comparative analysis of current HSI policies and procedures 
utilized by the Navy. 

Identify the significant gaps in guidelines and policies in service 
documentation and implementation. 

Propose strengthened policy, based on the information and knowledge 
gathered from the current framework and gaps, to improve the efficiency 


and effectiveness of the acquisition process. 


D. RESEARCH QUESTIONS 


This thesis poses the question: What modifications can be made within the Navy, 


and the acquisition process as a whole, to better address and improve the application of 


HSI in the Acquisition, Technology and Logistics (AT&L) framework? 


In addressing the question above, the following questions were also considered: 


What are the objectives of DoDD 5000.02 with respect to HSI 
requirements for the U.S. Navy? 

What policies, procedures, and infrastructures currently exist within the 
U.S. Navy to carry out HSI? 

What gaps exist between the current policies, procedures, and 
infrastructure? 


If gaps do exist, how can these gaps be closed? 


E. METHODOLOGY 


This thesis analyzes how the U.S. Navy integrates human considerations and HSI 


into the IDAT&L Framework. Generalizations regarding the entire HSI program for the 


U.S. Navy are based on the details of the analysis of instruction and policy that have been 


published. This thesis critically evaluates U.S. Navy policy and guidance for conducting 
HSI and recommends proposed solutions to fill gaps in the policy. 

This thesis first establishes a baseline of HSI requirements among all Navy 
acquisition programs as outlined in the Department of Defense Directive (DoDD) 
5000.02. This baseline is used to establish a way in which HSI programs and policy are 
evaluated. Additionally, this thesis identifies gaps in all documents that need to be 
addressed in order to have coherent HSI policy and guidance. These gaps, found through 
document review and structured interviews, are later used to recommend revisions to 
DoD policy and to establish a joint framework for conducting HSI throughout the entire 
Life Cycle of a program. 

Based on the results of the analysis, this thesis recommends revisions to HSI 
policy that seek to reduce Life Cycle cost, improve total system performance, and 
enhance quality of life for the end users, namely the Sailors and Marines who are 
defending this country on a daily basis and who will ultimately reap the benefits of this 
work. Those who make decisions throughout the DoD systems will be better informed, 
will understand how to mitigate Life Cycle costs, and will begin to recognize the human 
as a critical factor in any system throughout the entire Life Cycle process. The benefits 
may be difficult to measure at first, but over time there will be a greater understanding of 
HSI, which will lead to a better understanding of the trade-offs that occur whenever a 
system is developed. 

The information presented in this thesis was gathered from a literature review of 
other texts, periodicals, directives, articles, and regulations pertaining to HSI in the DoD 


acquisition process. 


F. SCOPE AND LIMITATIONS 


This thesis assumes that the reader understands the basic principles and current 
policies governing DoD systems acquisition and program management, as well as DoD 
and Navy organizations involved therein. Further, it assumes that the reader has a limited 
knowledge of HSI and will therefore explain HSI concepts and procedures in detail. This 
thesis focuses on the implementation of HSI through a materiel solutions approach. It is 


important to understand that HSI is also critical to the process of implementing a 
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nonmateriel approach and solution through the use of DOTMLPF; however, nonmateriel 


approaches are not within the scope of this thesis. 


G. ORGANIZATION 


The remainder of the thesis is organized as follows: Chapter II provides the 
approach used to determine the effectiveness of current policy and how gaps are 
identified. Chapter III describes a model created to serve as the ideal case, 1.e., a way in 
which DoD HSI policy could be comprehensive and complete. This model serves as the 
goal for future DoD HSI policy and guidance, from which analysis and recommendations 
are taken. Chapter IV identifies and describes the gaps found between current policy and 
our ideal model for this level of documentation. Chapter V proposes recommendations 
based on the gap analysis to improve the HSI policy within the U.S. Navy. Chapter VI 
summarizes the conclusions derived from the document analysis as well as the new 


framework recommendations. 


I. APPROACH 


A. DESIGN 


In order to conduct a gap analysis of the current documentation pertaining to HSI 
within the U.S. Navy, we first propose an ideal conceptual model, which is explained in 
detail in Chapter III. This model is used to measure the effectiveness of the current HSI 
policy and to identify the gaps within the policy. This approach does not involve studying 
individuals, but instead relies on analytical thought and critiques of current DoD policy 
and guidance. The documents chosen for analysis were: 
e DoDD 5000.1 (2003) 
e DoDI 5000.02 (2008) 
e CHAIRMAN OF THE JOINT CHIEFS OF STAFF INSTRUCTION 
(CJCSD 3170.01F (2007) 

e OFFICE OF THE CHIEF OF NAVAL OPERATIONS INSTRUCTION 
(OPNAVINST) 5310.23 (2008) 

e SECRETARY OF THE NAVY INSTRUCTION (SECNAVINST) 
5000.2D (2008) 

° VIRTUAL SYSCOM (VS) HSI GUIDE VOLUME I (2005) 

® VS HSI GUIDE VOLUME II (2005) 

e NAVAL SEA SYSTEMS COMMAND HUMAN SYSTEMS 

ENGINEERING (NAVSEA HSE) CODE OF BEST PRACTICES (2008) 


B. DESCRIPTION OF IDEAL MODEL 


Microsoft Visio was used to construct a visual representation of the ideal model. 
A system engineering/JCIDS approach was used to create a functional needs analysis to 
break down each component from the highest to the lowest possible level. Each separate 
item in the model was deemed important to HSI, based on the IDAT&L Life Cycle 
Management Framework. In order to be less biased, current policy and guidance was not 
used when creating this model, which serves as an ideal model, without reference to 


current policy. 


C. HYPOTHESIS 


There are significant gaps in documentation of HSI policy and guidance at all 


levels throughout the Department of the Navy (DoN). 


D. PROCEDURE 


Each reference (policies, guidance, etc.) used in this thesis was assigned a priority 
level, based on the hierarchical structure of the U.S. Navy. This priority level has 
associated elements within the model that should be incorporated in the documentation at 
that level. In order to identify the gaps, each document was read closely and analyzed as 
it currently stands, looking for the associated elements that should be contained in it 
according to the ideal model. The elements not contained within the document were 
identified as gaps. After all documents were analyzed individually, three tracks were 
created pertaining to the three major U.S. Navy Systems Commands (SYSCOMs): Naval 
Sea Systems Command (NAVSEA), Naval Air Systems Command (NAVAIR), and 
Space and Naval Warfare Systems Command (SPAWAR). Each of these tracks began at 
the highest level, the DoD, and ended at the specified SYSCOM. This allowed us to not 
only identify gaps within individual documents, but also to identify gaps as a whole 
within the Navy’s acquisition structure. Recommendations were made for filling each gap 


within the parameters of the current references as well as within each SYSCOM track. 
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Ht. IDEAL MODEL 


A. BACKGROUND ON THE IDEAL MODEL 


This chapter explains the methodology used in creating our ideal model for HSI 
policy throughout the U.S. Navy. It enables the reader to follow the systematic approach 
taken to analyze HSI policy and guidance that exists in the DoN. This ideal model was 
created based on the existing Integrated Architecture (IA) and existing policy and 
guidance, and drew on our knowledge and understanding of the HSI process. The 
existing IA was created by numerous individuals from the U.S. Navy’s HSI Virtual 
Systems Command (VSYSCOM). We have amended portions of the IA to implement the 
policy that plays an important role in HSI throughout the Navy. 

In conjunction with the IA, members of the U.S. Navy Virtual SYSCOM use a 
program called the Human Analysis and Requirements Planning System (HARPS), 
which is a tool that allows the identification of automation through development of the 
HSI JA. The IA is embedded in HARPS and, by using the IA as the basis for the ideal 
model, by default HARPS is incorporated in the model. 

Policy is the basis for all tasks in the Navy. It mandates the tasks that should be 
done, without explicitly stating how they are to be done. Policy creates a common 
baseline to guide the SYSCOM through complex undertakings. To effectively mandate a 
specific task, it should be fully specified throughout all levels of authority. In the absence 
of appropriate policy, breakdowns may occur regarding specific requirements to 
accomplish the necessary goal. These breakdowns can have significant effects, especially 
if policy at the highest levels is lacking or unclear. Due to this potential shortcoming, 
policy is a large part of this ideal model, and results in our model differing substantially 
from the IA. Our focus on policy allows us to analyze gaps in the IDAT&L Life Cycle 


Management Framework as well as the policies pertaining to HSI. 


The IA was developed to provide the SYSCOMs with guidance in the application 
of HSI, and is complex and detailed in nature. Our ideal model is based on the current IA, 


but is specifically designed to analyze the full range of policy covered by the DoD. We 
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do not suggest that the ideal model optimizes HSI. Rather, it provides a comprehensive 


coverage that ensures that HSI is being fully implemented at all levels. 


B. PURPOSE 


The objective of creating this ideal model is to provide an overview of HSI policy 
that allows HSI practitioners the ability to recognize shortcomings in current policies and 
guidance. The end goal of HSI is to integrate the human into all aspects of the system 
design and acquisition process. It focuses on human performance and trade-offs, given 
the specifications of each individual system. These short-comings are referred to as gaps, 
and their identification allows policy makers to see where changes need to be made in the 
existing policy to ensure HSI is being performed efficiently and that the appropriate 


people are involved in its delivery. 


C. STRUCTURE OF MODEL 


This section describes the ideal model in a systematic manner. The ideal model, 
and a brief explanation of each item, is seen in Figure 1. In order to create a mental 
picture for the reader, we have condensed the model onto one page. In the Appendix, the 
complete model is laid out on multiple pages to allow the reader the ability to read the 


text of the model. 
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1.—Do HSI 
“The process of conducting Human Systems Integration is intended to 
integrate human-related issues into the development of the product by 
identifying specific human-related and mission-related performance and 
system design requirements, communicating those requirements 
throughout the design process, and ensuring those requirements are met” 
(Virtual SYSCOM (VS), Vol. 2, 2005, p. 12). 

1.1 — Establish Policy 
A planned course of action that sets forth guiding principles and 
procedures for ensuring HSI is properly embedded throughout the entire 
acquisition strategy, to produce the most advantageous products to the 
user, at the lowest possible cost. 

1.1.1 — Establish HSI Reporting Authority 
A structure created to ensure an open line of communication throughout 
all organizations in HSI and the Acquisition Framework, from top to 
bottom, to effectively track and report all HSI-relevant areas and provide 
oversight for successful program acquisition. 

1.1.1.1 — Operational Reporting Authority 
The Operational Reporting Authority is tasked with “the employment of 
the forces provided by the administrative chain of command, in order to 
carry out missions in support of the National Defense” (Naval Officers 
Guide, 1998, p. 185). Since an Operational Reporting Authority already 
exists in the Navy, HSI practitioners shall be embedded at all levels 
throughout the reporting authority to ensure open lines of communication 
and provide oversight in a successful program acquisition. 

1.1.1.1.1 — Identify Roles/Key Players in Operational Reporting Authority 
Job title and description for key players serve as part of the operational 
reporting authority. In addition to meeting the requirements for the 
specific job description, these key personnel must also be HSI practioners 


with documented education and experience. 
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1.1.1.1.1.1 — Identify HSI Key Organizations Throughout the Life Cycle 


Organizations throughout the DoD and DoN are responsible for 


implementing and overseeing the HSI process at various stages throughout 


the IDAT&L Life Cycle. These HSI organizations exist within larger 


organizations that are stakeholders in the acquisition process. 
1.1.1.1.1.1.1 
O DoD Level 


Refers to DoD and Chairman of the Joint Chiefs of Staff 


(CJCS) offices. 


O Service Level 


Refers to the Office of the Chief of Naval Operations (OPNAV) 
and the Office of the Secretary of the Navy (SECNAYV) as well 


as VSYSCOM. 


O Command Level 


Refers to the System Commands (NAVSEA, NAVAIR, and 


SPAWAR). 
1.1.1.2 — Administrative Reporting Authority 


The administrative chain of command is tasked with manning, training, 


and equipping forces. Since an Administrative Reporting Authority 


already exists in the Navy, HSI practitioners shall be imbedded at all 


levels throughout the reporting authority to ensure open lines of 


communication and provide oversight in a successful program acquisition. 


1.1.1.2.1 — Identify Roles/Key Players in the Administrative Reporting 


Authority 


Identifies the job title and description for key players that serve as part of 


the Administrative Reporting Authority. In addition to meeting the 


requirements for the specific job description, these key personnel must 


also be HSI practioners, with documented education and experience. 
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1.1.1.2.1.1 — Identify HSI Key Organizations Throughout the Life Cycle 
Organizations throughout the DoD and DoN that are responsible for 


implementing and overseeing the HSI process at various stages throughout 
the IDAT&L Life Cycle. These HSI organizations exist within larger 
organizations that are stakeholders in the acquisition process. 


1.1.1.2.1.1.1 
O DoD Level 


Refers to DoD and CJCS offices. 
O Service Level 
Refers to OPNAV and SECNAV as well as VSYSCOM. 
O Command Level 
Refers to the System Commands (NAVSEA, NAVAIR, 
and SPAWAR). 
1.1.2 — Define HSI and Domains 
“HSI acknowledges that the human is a critical component of any complex 
system. It is an interdisciplinary approach that makes explicit the underlining 
tradeoffs across the HSI domains, facilitating optimization of total system 
performance” (Miller & Shattuck, 2006, p. 4). The domains of HSI are: 
Manpower, Personnel, Training, Human Factors Engineering, Survivability, 
Habitability, Environment, Safety, and Occupational Health. 
1.1.2.1 — Apply Defined HSI Domains 
Incorporate all HSI domains listed above to effectively optimize total system 
performance. Application of all domains will allow for complete 
trade-off analysis. 
1.1.3.1 — Ensure Integration of Domains 
“Identify desirable and practical alternatives among requirements, technical 
objectives, design, program schedule, functional and performance requirements 


and Life Cycle costs to optimize human performance” (VS, Vol. 2, 2005, p. 14). 
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1.2 — Participate in IDAT&L Life Cycle Management Framework 
Actively engage in all prescribed portions of the framework, from beginning to 


end, to ensure HSI is integrated throughout the entire framework. 

1.2.1 — Identify HSI Key Players Throughout the Life Cycles’ Phases 
Identify personnel throughout the DoD and DoN that are responsible for 
implementing and guiding the HSI process at various stages throughout the 
IDAT&L Life Cycle. These HSI personnel are members of a stakeholder 
command in the acquisition process. 

1.2.1.1 - Transition Criteria from JCIDS to the Materiel Solutions Analysis Phase 
“Entry point to begin translating the HSI requirements established in JCIDS into 
materiel solutions phase by balancing technology opportunities, schedule 
constraints, funding availability, performance parameters, and operational 
requirements” (VS, Vol. 2, 2005, p. 16). 

1.2.1.1.1 — Subset of 1.2.1.1 
Functional Area Analysis 
“Identifies the mission area or mission problem to be assessed, the concepts to be 
examined, the timeframe in which the problem is being assessed, and the scope of 
the assessment, and describes the relevant objectives and concept of operations 
(CONOPs) or concepts and the relevant effects to be generated” (Defense 
Acquisition University (DAU), 2005, p. B-66 ) 
Functional Needs Analysis 
“Assesses the ability of the current and programmed war fighting systems to 
deliver the capabilities of the Functional Area Analysis identified under the full 
range of operating conditions and to the designated measures of effectiveness. 
The FNA produces a list of capability gaps that requires solutions and indicates 
the time frame in which those solutions are needed. It may also identify 


redundancies in capabilities that reflect inefficiencies” (DAU, 2005, p. B-67) 
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Functional Solutions Analysis 
“Operationally assess all potential doctrine, organization, training, materiel, 


leadership and education, personnel and facilities (DOTMLPF), approaches to 
solving (or mitigating) the capability gaps (needs) identified in the Functional 
Needs Analysis (FNA), highlighting human systems impacts” (VS, Vol. 2, 2005, 
p. 14). 
HSI Action Plan 
“Document plans to implement HSI within the acquisition process, emphasizing 
customer involvement, definition of processes for implementing, integration of all 
HSI domains, acquisition activities, work plans, and resources” (VS, Vol. 2, 2005, 
p. 18). This will not be a stand-alone document; it will be integrated with the 
systems engineering plan(s). 
Acknowledgement of Materiel Solution 
“Identify the HSI domain impacts of the proposed materiel solutions” (VS, Vol. 2, 
2005, p. 15). 
Initial Capabilities Document 
“Generate the HSI inputs for the ICD and review the overall HSI inclusion and 
integration” (VS, Vol. 2, 2005, p. 16). 

1.2.1.2 — Materiel Solutions Analysis Phase (MSA) 
“The purpose of this phase is to assess potential materiel solutions and to satisfy 
the phase-specific entrance criteria for the next program milestone designated by 
the MDA” (DoD, 2008, p. 14). 

1.2.1.2.1 — Subset of 1.2.1.2 
Analysis of Alternatives (AoA) Plan 
“Perform HSI assessment of advantages and disadvantages of alternatives being 
considered to satisfy capabilities, including a sensitivity of each alternative to 
possible changes in key assumptions or variables. These assessments should be 
considered in selection of the preferred materiel solution” (VS, Vol. 2, 2005, p. 


19). 
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Technology Development Strategy 
“Assure Request for Proposal (RFP) includes HSI domain and integration 


requirements within the Statement of Work (SOW), Specification and Contract 
Data Requirements. Review and evaluate contractor response to RFP for HSI 
considerations to approach, cost estimate, and resources” (VS, Vol. 2, 2005, p. 
23). 


Test and Evaluation Strategy 
This is a document “that describes risk reduction efforts across the range of 


activities that will ultimately produce a valid evaluation of operational 
effectiveness, suitability, and survivability before full-rate production and 
deployment” (DAU, 2004, p. 477). 

Materiel Development Decision 

This allows a program to enter into the Acquisition Framework/system. It is a 
mandatory decision point that is developed from the initial capabilities document 
(ICD), as well as all preliminary concepts, needs, and capabilities, and allows 
optimal trade-offs to be performed. 

System Engineering Plan 

This is a “program’s overall technical approach including the systems engineering 
process; resources; and key technical tasks, activities, and events along with their 
metrics and success criteria. Integration and linkage with other program 
management control efforts is fundamental to successful application. This plan 
must address the who, what, when, where, why and how of the applied system” 
(DAU, 2004, p. 166). 

HSI Action Plan 

“Document plans to implement HSI within the acquisition process emphasizing 
customer involvement, definition of processes for implementing, integration of all 
HSI domains, acquisition activities, work plans, and resources. Additionally, this 
includes the aggregation of all inputs available at this stage of the program to 
ensure that all HSI needs and constraints of the concept definition are completely 
captured and managed as an integrated whole, and that all of the HSI needs and 


constraints can be met by each of the concept alternatives under consideration” 
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(VS, Vol. 2, 2005, p. 18). This will not be a stand-alone document; it will be 
integrated with the systems engineering plan(s). 

Support and Maintenance Concepts 

“{Support and] maintenance considerations, constraints, and plans for operational 
support of the system/equipment under development” (DAU, 2005, p. B-97) 

Cost and Manpower Estimates 

“The estimate of dollars and personnel required to operate, maintain, support, and 
provide system-related training, in advance of the approval of the development, or 
production and deployment of the system. These estimates should be consistent 
with manpower levels assumed in the affordability assessment and cost 
requirements” (DAU, 2004, p. 52). 

Alternative Concepts 

“Identify desirable and practical alternatives among requirements, technical 
objectives, design, program schedule, functional and performance requirements 
and Life Cycle cost to optimize human performance” (VS, Vol. 2, 2005, p. 14). 
User Input/Feedback 

The user needs to provide their needs and constraints to the manufacturer in order 
to keep the program aligned with the initial demand of the user. 

Initial Capabilities Document 

“Generate the HSI inputs for the ICD and review the overall HSI inclusion and 
integration” (VS, Vol. 2, 2005, p. 16). 

Preliminary System Specification 

“States the [initial] system level functional and performance requirements, 
interfaces, adaptation requirements, security and privacy requirements, computer 
resource requirements, design constraints (including software architecture, data 
standards, programming language), software support and _ precedence 
requirements, and developmental test requirements for a given system” (DAU, 
2005, p. B-161) 


Initial Training Systems Plan 
“Develop a_ training/instructional system that should be employed by 


transformational training concepts, strategies, and tools such as computer based 
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and interactive courseware, simulators, and embedded training consistent with 
strategy, goals and objectives of the proposed system” (DAU, 2004, p. 253). 
Draft Key Performance Parameters (KPPs) 
“{Draft] attributes or characteristics of a system that are considered critical or 
essential to the development of an effective military capability and those 
attributes that make a significant contribution to the key characteristics as defined 
in the Joint Operations Concept [especially in the HSI domains]” (DAU, 2005, p. 
B-91) 
Name Materiel Solution Manager 
Materiel Solution Manager “is responsible for managing the HSI related program 
requirements from concept to disposal, bringing together all stake holders and 
involving industry (except during competition phases) under their leadership and 
must be able to balance trade-offs between performance, cost and time within 
boundaries set by the approving authority” (VS, Vol. 2, 2005, p. 17). 
System Concept 
“A formal document that describes the intended purpose, employment, 
deployment, and support of a system” (DAU, 2005, p. B-161) 

1.2.1.3 — Transition Criteria from Material Solutions Analysis (MSA) to Technology 
Development (TD) (Milestone A) 
Transition between phases is delineated by requirements that must be met before 
entrance to the next phase. 


1.2.1.3.1 — Subset of 1.2.1.3 
Draft Capability Development Document (CDD) 


“A [draft] document that captures the information necessary to develop a 
proposed program [throughout the Life Cycle]. The CDD outlines an affordable 
increment of militarily useful, logistically supportable, and technically mature 
capability” (CJCSI 3170.01G, 2009, GL-5). 

Milestone Exit Criteria 

“The point at which a recommendation is made and approval sought regarding 


starting or continuing an acquisition program, i.e., proceeding to the next phase” 
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(DAU, 2005, p. B-104). The purpose is to establish (at the beginning of each 
phase) what criteria must be met to exit that phase. 
1.2.1.4 — Technology Development (TD) Phase 
“This phase reduced technology risk and determines the appropriate set of 
technologies to be integrated into a full system. Technology development is a 
continuous technology discovery and development process that reflects close 
collaboration between the science and technology community, the user, and the 
developer. Technology development is an iterative process of assessing 
technologies and refining user performance parameters” (VS, Vol. 2, 2005, p. 22). 
1.2.1.4.1 — Subset of 1.2.1.4 
Information Support Plan (ISP) 
“The ISP contains interface descriptions, infrastructure and support requirements, 
standards profiles, measures of performance, and interoperability shortfalls” 
(DAU, 2005, p. B-79) 
Systems Performance Specification 
A plan that delineates the specifications required by the user for a successful 
completion. These specifications include, but are not limited to, test methods, 
performance testing requirements, safety considerations and requirements, 
environmental considerations and requirements, as well as quality and 
completion requirements. 
Acquisition Strategy 
“A business and technical management approach designed to achieve program 
objectives within the resource constraints imposed. It is the framework for 
planning, directing, contracting for, and managing a program. It provides a master 
schedule for research, development, test, production, fielding, modification, 
postproduction management, and other activities essential for program success. 
The acquisition strategy is the basis for formulating functional plans and 


strategies” (DAU, 2005, p. B-4) 


me 


Footprint Reduction 

Reduce footprints through the use of alternative concepts/solutions to mitigate the 
negative effects of a particular footprint. 

Affordability Assessment 

“[An assessment generating a] determination of the Life Cycle Cost of an 
acquisition program in consonance with the long-range investment and force 
structure plans of the DoD or individual DoD Components” (DAU, 2005, p. B-7) 
KPPs 

“Attributes or characteristics of a system that are considered critical or essential to 
the development of an effective military capability and those attributes that make 
a significant contribution to the key characteristics as defined in the Joint 
Operations Concept [especially in the HSI domains]” (DAU, 2005, pg. B-91) 

HSI Action Plan 

“Document plans to implement HSI within the acquisition process emphasizing 
customer involvement, definition of processes for implementing, integration of all 
HSI domains, acquisition activities, work plans, and resources” (VS, Vol. 2, 2005, 
p. 18). This will not be a stand-alone document; it will be integrated with the 
systems engineering plan(s). 

Test and Evaluation (T&E) Master Plan 

“Documents the overall structure and objectives of the Test and Evaluation (T&E) 
program. It provides a framework within which to generate detailed T&E plans 
and it documents schedule and resource implications associated with the T&E 
program. The TEMP identifies the necessary Developmental Test and Evaluation 
(DT&E), Operational Test and Evaluation (OT&E), and Live Fire Test and 
Evaluation (LFT&E) activities. It relates program schedule, test management 
strategy and structure, and required resources to: Critical Operational Issues 
(COIs), Critical Technical Parameters (CTPs), objectives and_ thresholds 
documented in the Capability Development Document (CDD), evaluation criteria, 


and milestone decision points” (DAU, 2005, B-166). 
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Integrated Baseline Review 

“Review of the Performance Measurement Baseline used to determine 
compliance and integration of domain related topics throughout the system” 
(DAU, 2005, p.B-82). 

Manpower Estimates 

“The estimate of personnel required to operate, maintain, support, and provide 
system-related training, in advance of the approval of the development, or 
production and deployment of the system. These estimates should be consistent 
with manpower levels assumed in the affordability assessment and cost 
requirements” (DAU, 2004, p. 68). 

System Threat Assessment 

Assessment made to summarize “significant changes in the threat environment as 
well as a discussion of the operational threat environment, adversary capability(s) 
[sic] that may affect operation of the system, system specific threat, reactive 
threat, and technologically feasible threats” (DAU, 2004, p. 392). 

User Input/Feedback 

The user needs to provide their needs and constraints to the manufacturer in order 
to keep the program aligned with the initial demand of the user. 

Proposed Training Systems Plan 

“Document and update the initial “training/instructional system that should be 
employed by transformational training concepts, strategies, and tools such as 
computer based and interactive courseware, simulators, and embedded training 
consistent with strategy, goals and objectives of the proposed system” (DAU, 
2004, p. 253). 

Technology Readiness Assessment 

“The system components are substantiated (e.g., through analyses, modeling and 
simulation, demonstrations, etc.) to allow verification of the components into an 


overall system for further validation” (VS, Vol. 2, 2005, p. 27). 
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System Support and Maintenance Objectives 

“(Support and] maintenance considerations, constraints, and plans for operational 
support of the system/equipment under development” (DAU, 2005, p. B-97). 
Programmatic Environment, Safety, and Health Evaluation (PESHE) 
Develop design options and specific design requirements to satisfy requirements 
in the areas of Environment, Safety, and Occupational Health. 

Systems Engineering Plan 

“This is a program’s overall technical approach including the systems engineering 
process; resources; and key technical tasks, activities, and events along with their 
metrics and success criteria. Integration and linkage with other program 
management control efforts is fundamental to successful application. This plan 
must address the who, what, when, where, why and how of the applied system” 
(DAU, 2004, p. 80). 


Program Protection Plan 
“[A plan set forth to] safeguard defense systems and Technical Data (TD) 


anywhere in the acquisition process, to include the technologies being developed, 
the support systems, [within military and HSI applications]” (DAU, 2005, p. B- 
133). 

Domain Implications 

Specific side effects of domain integration and trade-offs throughout the system. 
By incorporating domain integration, a hierarchy of priorities must be established 
to optimize the system through conducting the necessary trade-offs. 

Preliminary Design Review (PDR) 

The PDR will inform requirement trades; improve cost estimation; and indentify 
remaining design, integration, and manufacturing risk. The PDR shall be 
conducted at the system level and include user representatives (DoD, 2008). 

Risk Assessment 

“Identification and analysis of potential cost and risk to the program plan. The 
risk assessment should include but not be limited to cost, performance, and 


schedule” (VS, Vol. 2, 2005, p. 28). 
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1.2.1.5 — Transition From TD to Engineering and Manufacturing Development 
(EMD) (Milestone B) 
Transition between phases is delineated by requirements that must be met before 
entrance to the next phase. 

1.2.1.5.1 — Subset of 1.2.1.5 
Milestone Exit Criteria 
“The point at which a recommendation is made and approval sought regarding 
starting or continuing an acquisition program, i.e., proceeding to the next phase” 
(DAU, 2005, p. B-104). The purpose is to establish (at the beginning of each 
phase) what criteria must be met to exit that phase. 
CDD 
“Primary means of defining authoritative, measurable, and testable capabilities 
needed by the war fighters to support the EMD phase” (DAU, 2004, p. 220). The 
CDD focuses on affordability, reliability, and supportability. 
Name PM 
Identify and establish a PM to effectively work with the Materiel Solution 
Manager in order to ensure the continuity of the work previously done, as well as 
maintain effective use of HSI domain practitioners throughout the rest of the 
Life Cycle. 

1.2.1.6 - EMD Phase 
“The initial HSI activity in this phase is to develop human-centered design 
concepts in the context of alternative system design concepts. HSI concepts 
include human-machine interfaces, human-computer interface (HCI), 
workstations, procedures/documentation/decision aiding, work space/facility, 
maintainability design, safety and health hazard avoidance design and training 
systems design. The purposed of EMD is to develop a system; reduce integration 
and manufacturing risk; ensure operationally supportability with particular 


attention to reducing the logistics footprint; implement HSI; design for product 
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ability; ensure affordability and protection of Critical Program Information (CPI); 
and demonstrate system integration, interoperability, safety, and utility” (VS, Vol. 
2, 2005, p. 29). 

1.2.1.6.1 — Subset of 1.2.1.6 
HSI Action Plan 
“Document plans to implement HSI within the acquisition process emphasizing 
customer involvement, definition of processes for implementing, integration of all 
HSI domains, acquisition activities, work plans, and resources” (VS, Vol. 2, 2005, 
p. 18). This will not be a stand-alone document; it will be integrated with the 
systems engineering plan(s). 


Product Support Package 
“Identify the activities, resources, schedule and critical integration requirements 


for the current phase” (VS, Vol. 2, 2005, p. 31). 
ISP 
“The ISP contains interface descriptions, infrastructure and support requirements, 
standards profiles, measures of performance, and interoperability shortfalls” 
(DAU, 2005, p. B-79) 
PESHE 
Develop design options and specific design requirements to satisfy requirements 
in the areas of Environment, Safety, and Occupational Health. 
Integrated System Design 
Combine all inputs available at this stage of the program to ensure that all HSI 
needs and constraints of the concept are completely captured and managed as an 
integrated whole, and that all of the HSI needs and constraints can be met by each 
of the concept alternatives under consideration. 
Approved Training Systems Plan 
Finalize the “training/instructional system that should be employed by 
transformational training concepts, strategies, and tools such as computer based 
and interactive courseware, simulators, and embedded training consistent with 
strategy, goals and objectives of the proposed system” (DAU, 2004, p. 253). 
Critical Design Review (CDR) 

27 


“A multi-disciplined technical review to ensure that a system can proceed into 
fabrication, demonstration, and test and can meet stated performance 
requirements within cost, schedule, risk, and other system constraints. Generally 
this review assesses the system final design as captured in product specifications 
for each configuration item in the system’s product baseline, and ensures that 
each configuration item in the product baseline has been captured in the detailed 
design documentation” (DAU, 2004, p. 127). 


Systems Engineering Plan 
“This is a program’s overall technical approach including the systems engineering 


process; resources; and key technical tasks, activities, and events along with their 
metrics and success criteria. Integration and linkage with other program 
management control efforts is fundamental to successful application. This plan 
must address the who, what, when, where, why and how of the applied system” 
(DAU, 2004, p. 80). 

Configuration Items Component-Level Specification 

“Comprehensive and iterative processes to convert each required capability into a 
system performance specification; translate user-defined performance parameters 
into configured systems; integrate the technical inputs of the entire design system; 
transition technology from the technology based into program specific efforts; and 
verify that designs meet operational needs” (VS, Vol. 2, 2005, p. 31). 

Key Performance Parameters (KPPs) 

“Attributes or characteristics of a system that are considered critical or essential to 
the development of an effective military capability and those attributes that make 
a significant contribution to the key characteristics as defined in the Joint 
Operations Concept [especially in the HSI and/or HSI domains]” (DAU, 2005, p. 
B-91) 

User Input/Feedback 

The user needs to provide their needs and constraints to the manufacturer in order 
to keep the program aligned with the initial demand of the user. 


Initial Product Baseline 
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“Construct or assemble hardware and software components and material to 
support human components, specified by the system design and maintenance 
concept” (VS, Vol. 2, 2005, p. 43). 


T&E Report 
A report of the findings found during T&E, specifically citing HSI domains and 


human interactions as found through the Operational and Developmental Test and 
Evolution events. 
OT&E 
“Through [Operational] Test and Evaluation events and other activities verify and 
validate, the design solutions relating to the entire system, but specifically 
highlighting HSI domains that satisfy requirements. Perform evaluations at the 
total system level, demonstrating performance in the expected operational 
environment. Operational environment includes operational supportability and 
interoperability” (VS, Vol. 2, 2005, p. 35). 
DT&E 
“Through [Developmental] Test and Evaluation events and other activities, verify 
and validate, the design solutions relating to HSI domains to satisfy requirements” 
(VS, Vol. 2, 2005, p. 35). 
Post-PDR Assessment 
Assessment conducted by the PM and Milestone Decision Authority to ensure 
that the PDR report reflects any requirements trades based on the assessment of 
cost, schedule, and performance risk (DoD, 2008). 
Post-CDR Assessment 
Assessment considers whether, based on the PM’s report, the program is able to 
provide capability consistent with the acquisition baseline approved at Milestone 
B (DoD, 2008). 

1.2.1.7 — Transition from EMD to PD (Milestone C) 
Transition between phases is delineated by requirements that must be met before 
entrance to the next phase. 

1.2.1.7.1 — Subset of 1.2.1.7 
Milestone Exit Criteria 

29 


“Conduct documentation reviews and other activities to complete approval and 
publication of program documentation” (VS, Vol. 2, 2005, p. 36). The purpose is 
to establish (at the beginning of each phase) what criteria must be met to exit that 
phase. 
CPD 
“Document contains refined/desired operational capabilities and expected system 
performance that are used throughout the test and evaluation phase. These inputs 
are used to update the Test and Evaluation Master Plan for the Milestone C 
decision and subsequent updates later in production and deployment. [This 
document] focuses on evaluation of the systems’ operational effectiveness, 
suitability, and survivability” (DAU, 2004, p. 431). 

1.2.1.8 — Production and Deployment (PD) Phase 
“The system is produced and fielded, continually undergoing test and evaluation 
to ensure that it is being implemented as designed and that the design will meet 
mission requirements. During the Production and Deployment Phase, the system 
should achieve operational capability that satisfies mission needs. During this 
phase the production and deployment team is responsible for managing the HSI 
related program requirements from concept to disposal, bringing together all 
stakeholders and Industry to balance tradeoffs between performances, cost and 
time” (VS, Vol. 2, 2005, p. 37). 

1.2.1.8 .1 — Subset of 1.2.1.8 
HSI Action Plan 
“Document plans to implement HSI within the acquisition process emphasizing 
customer involvement, definition of processes for implementing, integration of all 
HSI domains, acquisition activities, work plans, and resources. This will be a 
stand alone document” (VS, Vol. 2, 2005, p. 18). 
User Input/Feedback 
The user needs to provide their needs and constraints to the manufacturer in order 
to keep the program aligned with the initial demand of the user. 


Production Baseline 
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“The document which describes the [baseline] for employment of the 
manufacturing resources to produce the required products or systems, on time, 
and within cost constraints” (DAU, 2005, p. B-127). 

Operational Readiness Assessment 

“Evaluate prototypes, early production versions of the system, and training 
capabilities to identify areas in which performance of the fielded version may not 
be satisfactory. Review other evaluations of the system, preliminary user 
feedback, and training feedback to determine other possible shortcomings or other 
specific areas in which performance, effectiveness, or efficiency may be 
improved” (VS, Vol. 2, 2005, p. 39). 

Product Support Package 

“Identify the activities, resources, schedule and critical integration requirements 
for the current phase” (VS, Vol. 2, 2005, p. 41). 

Implement Maintenance Objectives 

“{Implement] maintenance considerations, constraints, and plans for operational 
support of the system/equipment under development” (DAU, 2005, p. B-97). 
PESHE 

Revise and develop design options and specific design requirements to satisfy 
requirements in the areas of Environment, Safety, and Occupational Health. 
Implement Training Plan 

Deploy/field “training/instructional system that should be employed by 
transformational training concepts, strategies, and tools such as computer based 
and interactive courseware, simulators, and embedded training consistent with 


strategy, goals and objectives of the proposed system” (DAU, 2004, p. 253). 
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Cost and Manpower Estimate 
“The estimate of dollars and personnel required to operate, maintain, support, and 


provide system-related training, in advance of the approval of the development, or 
production and deployment of the system. These estimates should be consistent 
with manpower levels assumed in the affordability assessment and cost 
requirements” (DAU, 2004, p. 52). 
Systems Engineering Plan 
“This is a program’s overall technical approach including the systems engineering 
process; resources; and key technical tasks, activities, and events along with their 
metrics and success criteria. Integration and linkage with other program 
management control efforts is fundamental to successful application. This plan 
must address the who, what, when, where, why and how of the applied system” 
(DAU, 2004, p. 80). 

1.2.1.9 — Operations and Support Phase 
“Operations and support includes the activities necessary to sustain the system— 
including training, maintenance, modernization, and upgrades - in a cost-effective 
manner throughout the Life Cycle. The operations and support team is responsible 
for managing HSI related program requirements from concept to disposal, 
bringing together all stakeholders and Industry to balance tradeoff between 
performance, cost, and time” (VS, Vol. 2, 2005, p. 40). 

1.2.1.9.1 — Subset of 1.2.1.9 
In-Service Review Data 
“Review existing data; participate in external - ongoing data collection activities; 
conduct focused human performance assessments; a model should include an 
issue repository that should be reviewable and accessible by all stakeholders” 


(VS, Vol. 2, 2005, p. 42). 
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Disposal Plan 
A plan that guides the demilitarization process and disposal in “accordance with 


all legal and regulatory requirements and policy relating to safety (including 
explosive safety), security, and the environment” (DoD, 2008, p. 29). 
Cost and Manpower Summary 
“The [actual number] of dollars and personnel required to operate, maintain, 
support, and provide system-related training, in advance of the approval of the 
development, or production and deployment of the system. These [numbers] 
should be consistent with manpower levels assumed in the estimates, affordability 
assessment and cost requirements” (DAU, 2004, p. 52). 
HSI Action Plan 
“Document plans to implement HSI within the acquisition process emphasizing 
customer involvement, definition of processes for implementing, integration of all 
HSI domains, acquisition activities, work plans, and resources. This will be a 
stand-alone document” (VS, Vol. 2, 2005, p. 18). 
Product Support Package 
“Identify the activities, resources, schedule and critical integration requirements 
for the current phase” (VS, Vol. 2, 2005, p. 17). 
PESHE 
Revise and develop design options and specific design requirements to satisfy 
requirements in the areas of Environment, Safety, and Occupational Health. 
Inputs to CDD (Next Increment) 
“Primary means of defining authoritative, measurable, and testable capabilities 
needed by the war fighters to support the EMD phase” (DAU, 2004, p. 220). The 
CDD focuses on affordability, reliability, and supportability. 
Revised Training Systems Plan (For Upgrades/Next Increment) 
Document and update the “‘training/instructional system that should be employed 
by transformational training concepts, strategies, and tools such as computer 
based and interactive courseware, simulators, and embedded training consistent 
with strategy, goals and objectives of the proposed system” (DAU, 2004, 
p. 253). 
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New Program Initiation 

Appropriate Life Cycle support organization designs and developments a detailed 
solution to address [new program initiatives]. 

Operation Readiness Assessment 

“Evaluate prototypes, early production versions of the system, and training 
capabilities to identify areas in which performance of the fielded version may not 
be satisfactory. Review other evaluations of the system, preliminary user 
feedback, and training feedback to determine other possible shortcomings or other 
specific areas in which performance, effectiveness, or efficiency may be 
improved” (VS, Vol. 2, 2005, p. 39). 

Life Cycle Sustainment 

“Life Cycle sustainment planning and execution seamlessly span a system’s entire 
Life Cycle, from materiel solution analysis to disposal. It translates force provider 
capability and performance requirements into tailored product support to achieve 
specified and evolving Life Cycle product support availability, reliability, and 
affordability parameters” (DoD, 2008, p. 28). 

Specifications for System Modifications/Upgrades 

“Evaluation, by applicable stakeholders, of alternative corrective actions to 
prioritize the solutions impact on the mission and fund the preferred system 
implementation in accordance with program constraints” (VS, Vol. 2, 2005, p. 
43). 

User Input/Feedback 

The user needs to provide their needs and constraints to the manufacturer in order 
to keep the program aligned with the initial demand of the user. 


Implement Maintenance Objectives 
“{Implement] maintenance considerations, constraints, and plans for operational 


support of the system/equipment under development” (DAU, 2005, p. B-97) 
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D. FUTURE OF MODEL 


The field of HSI continues to evolve and changes occur frequently. As gaps are 
identified, they are then filled, which will change the nature of the findings in this thesis. 
However, as HSI matures, the model proposed herein serves as a baseline on which to 


build. Modifications are expected and welcome, as they will enrich the field of study. 


E. SUMMARY 


As seen from the above definitions, we have provided both a model and 
operational definitions for each of the elements of the model to allow the reader to fully 
understand the criteria that is needed to address and fill the gaps in policy that are noted 
in the next chapter. These definitions allow us to find the gaps in current policy and 
address them accordingly. In the next chapter, a gap analysis is performed, based on the 
definitions found in this chapter, and recommendations are made to help close the 


noted gaps. 
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IV. GAP ANALYSIS OF DOCUMENTATION AND 
RECOMMENDATIONS 


A. ANALYSIS 


As mentioned in earlier chapters, each reference (policies, documents, etc.) used 
in this thesis were assigned a priority level based on the hierarchy of the Navy structure. 
This priority level has associated elements within the model that should be incorporated 
in the documentation at that particular level. In order to identify gaps in each document, 
we closely read and analyzed the current document, looking for areas that met the criteria 
laid out in the model. The elements that were not contained within the document, but 
were identified in the model, were noted as gaps and recorded in this chapter. 


Recommendations were then be made to identify ways to fill those recorded gaps. 


B. PRIORITY LEVEL OF DOCUMENTS 


The following documents were been broken down and were assigned a particular 
priority level based on the hierarchy of the authority from which the document was 
released. The references were assigned a level number ranging from 1 to 3, with | being 
the highest level of DoD and Navy authority and 3 being the lowest level as it relates to 
the IDAT&L Life Cycle Framework Management and HSI: 


DODD5000.1 LEVEL 1 
DODI 5000.02 LEVEL 1 
CJCSI 3170.01G LEVEL 1 
OPNAVINST 5310.23 LEVEL 2 
SECNAVINST 5000.2D LEVEL 2 
VS HSI GUIDE VOLUME I LEVEL 3 
VS HSI GUIDE VOLUME II LEVEL 3 
NAVSEA HSE CODE OF BEST PRACTICES LEVEL 3 
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C; MODEL BREAKDOWN 


Figures 2-4 are a depiction of the model used for the gap analysis, broken down 
by color, to show the minimum scope of responsibility for each level of documentation. It 
is important to remember that this breakdown is the bare minimum that must be 
contained in each document in order to establish a clear, understandable, and efficient 
guide to practice HSI within the IDAT&L Life Cycle Management Framework. 

There should be a fair amount of overlap in the model within consecutive levels. 
This shows that the information contained within a higher-level document is being 
carried out by the next lower level. The idea here is that the same principles that are put 
in place at the highest level are still valued and followed throughout all levels of 
documentation. Level 1 criterion is marked on the model in red. Level 2 criteria are 
marked on the model in green. Level 3 criteria are marked on the model in blue. 

The model is broken up into three separate figures to make it easier to read. The 
first figure (Figure 2) is the policy side of the Ideal Model. Figure 3 is the operational 
side of the model that spans through the TD Phase. Figure 4 is also the operational side of 


the model and covers the remainder of the life cycle through OS phase. 
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Figure 2. The Ideal Model (Policy Side) 


39 











T2.1.4.1 





V2.13.T 





Wa Nn 


/ 


a ae Ss a 





\ 





yoS> 





TTT 


Figure 3. 





The Ideal Model (Operational Side through TD) 
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The Ideal Model (Operational Side through OS) 


Figure 4. 
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D. DOCUMENT GAPS AT LEVEL 1 
1. DoDD 5000.1 


Although the purpose of this document is to “provide management principles and 
mandatory policies and procedures for managing all acquisition programs” (DoD, 2003, 
p. | (a)), this document fails to address the following criteria established by the model, 
therefore making them gaps in the current policy. We acknowledge that DoDI 5025.01 
constrains the length of DoD Directives to eight pages and, therefore, would limit the 
amount of information that can be addressed, but we feel that these gaps are very 
important to successful HSI implementation. We have included the portions of the model 
that pertain to each level to allow the reader to visually see where the gaps are in each 
level on the model for this specific document. The boxes that have a yellow outline/ dots 
around them are the gaps we have identified. Additionally, the gaps are also listed in 
bullet format. Figure 5 shows the gaps in the policy side of the model for this document. 
Figure 6 shows the gaps in the operational side of the model through TD for this 
document. Figure 7 shows the gaps in the operational side of the model through OS for 
this document. 

e Do HSI 

e Establish Policy 

e Participate in the IDAT&L Life Cycle Management Framework 

e Establish HSI reporting authority 

e Define HSI and domains 


e Identify HSI Key Players throughout the phases of the Life Cycle (DoD) 


e Materiel Solutions Analysis Phase 

e Technology Development Phase 

e Engineering and Manufacturing Development Phase 
e Production and Deployment Phase 

e Operations and Support Phase 
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Operational 
Reporting Authority 
1.1.1.1 


Identify Roles / Key 
Players in Operational 
Reporting Authority 


1.1.1.1.1 


Identify HSI Key 
Organizations Throughout 
Lifecycle 


1.1.1.1.1.1 


Figure 5. 


Administrative 
Reporting Authority 
1.1.1.2 


Identify Roles / Key 
Players in Administrative 
Reporting Authority 


1.1.1.2.1 


Identify HSI Key 
Organizations Throughout 
Lifecycle 


1.1.1.2.1.1 


1.1.1.2.1.1.1 


Apply Defined HSI 
Domains 
1.1.2.1 


Ensure Integration 
of Domains 


1.1.3.1 





Gaps Identified in DoDD 5000.1 (Policy Side) 
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Solutions Analysis Phase (Milestone Ay?-1 
1.2.13) 
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: System Engineering Plan ! 













System Threat 


HSI Action Plan : Support and Maintenance - Cost / Manpower 
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User Input / Feedback 












Proposed Training : : Technology Readiness ‘ : System Support and 
Systems Plan eit Assessment + Maintenance Objectives | 


Acknowledgement of 
Materiel Solution 





Alternative Concepts User Input / Feedback 
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Document 
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Figure 6. Gaps Identified in DoDD 5000.1 (Operational Side through TD) 
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Transition from TD to 
EMD 
(Milestone B) 












: Information Support Plan : 


Approved Training 
Systems Plan 





Configuration Items 
Component — Level 
Specification 





Operational Test and 


Evaluation Report 


Developmental Test and 
Evaluation 





Figure 7. 


Transition from EMD to 
PD (Milestone C) 
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Production Baseline 








Cost and Manpower 
Estimate 





: Operational Readiness - 
: Assessment : 


: Implement Maintenance - 
: Objectives : 


: Implement Training Plan : 





‘Systems Engineering Plan: 




















Cost and Manpower 


Summary HSI Action Plan 


: Product Support Package: 















‘Revised Training Systems: 
: Plan (for upgrades / next : 
increment) : 


Inputs to CDD (Next 
Increment) 


: Operational Readiness ° 
Assessment : 


Specifications for System : 
: Modifications / Upgrades : 


: Implement Maintenance - 
: Objectives iB 


Document lessons 
Learned 


1.2.1.9.1 


Gaps Identified in DoDD 5000.1 (Operational Side through OS) 


As noted from Chapter III, and the definitions of each of these phase items, this 
document misses the mark on all requirements for this level of documentation. We feel 
that it is important to lay a strong, solid, and well-defined foundation on which to build. 
Although this document does mention cost and affordability, integrated test and 
evaluation, interoperability, safety, systems engineering, technology development and 
transition, and total systems approach—all of which are essential to successfully 
implementing HSI—it neglects to lay the foundation for the importance of HSI within the 
IDAT&L Life Cycle Management Framework. Policy is mentioned in the document; 
however, it merely refers to the Defense Acquisition System as a whole, and does not 
mention HSI as part of that system. HSI is, however, mentioned as part of a total system 
approach that the PM is responsible and accountable to use, but no guidance is given as 
to any of the above items listed as gaps in the document. Overall, this document needs 
massive improvements in order to provide the necessary information to successfully 


adapt and use HSI throughout the IDAT&L Life Cycle Management Framework. 


2. DoDI 5000.02 


The purpose of this document is not only to implement DoDD 5000.1, but also to 
“establish a simplified and flexible management framework for translating capability 
needs and technology opportunities, based on approved capability needs, into stable, 
affordable, and well managed acquisition programs” (DoD, 2008, p. 1). This document, 
along with the other two documents at this level, should serve as the foundation for HSI 
to build on during the IDAT&L Life Cycle Management Framework. After analyzing this 
document, the items below are noted as gaps because the document fails to make 
reference to them in its current standing. We have included the portions of the model that 
pertain to each level to allow the reader to visually see where the gaps are in each level 
on the model for this specific document. The boxes that have a yellow outline are the 
gaps we have identified. Additionally, the gaps are also listed in bullet format. Figure 8 
shows the gaps in the policy side of the model for this document. Figure 9 shows the gaps 
in the operational side of the model through TD for this document. Figure 10 shows the 


gaps in the operational side of the model through OS for this document. 
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e Establish HSI Policy 


e Establish HSI Reporting Authority 


° Define HSI and Domains 


e Identify HSI Key Players throughout the phases of the Life Cycle 
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Figure 8. 
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Figure 10. Gaps Identified in DoDI 5000.02 (Operational Side through OS) 
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Based on the definitions provided in Chapter II, this document fails to adequately 
address the above items. DoDI 5000.02 places a heavy emphasis on the PM for 
implementing HSI throughout the acquisition process, but fails to identify any other 
specific players. The document makes an attempt at identifying the domains of HSI, but 
neglects to define HSI. Other items, such as user needs, T&E, cost estimation, and 
Systems Engineering, are incorporated into the document to provide insight and 
information as to the operation of these items within the acquisition process. The mention 
of these items does not negate the need for the foundation level items associated with 


level 1 documentation. 


3. CJCSI 3170.01F 


The purpose of this document is to establish the policies relating to the JCIDS. 
This document also serves as a foundation level document at the highest level of the 
DoD’s hierarchy. After reviewing this document, we concluded that the following gaps 
exist within the document as it is currently written. We have included the portions of the 
model that pertain to each level to allow the reader to visually see where the gaps are in 
each level on the model for this specific document. The boxes that have a yellow outline 
are the gaps we have identified. Additionally, the gaps are also listed in bullet format. 
Figure 11 shows the gaps in the policy side of the model for this document. Figure 12 
shows the gaps in the operational side of the model through TD for this document. Figure 
13 shows the gaps in the operational side of the model through OS for this document. 

e Do HSI 

e Establish HSI Policy 

e Establish HSI reporting authority 

e Identify HSI Key Players throughout the phases of the Life Cycle (DoD) 


e Materiel Solutions Analysis Phase 

e Technology Development Phase 

e Engineering and Manufacturing Development Phase 
e Production and Deployment Phase 

e Operations and Support Phase 
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Although this document misses the mark according the model on level 1 
requirement, it does establish several key processes that must take place in order to 
produce capabilities that will benefit the warfighter. These processes include the 
requirements process, the acquisition process, and the planning, programming, budgeting 
and execution (PPBE) process. It walks through the entire JCIDS process, beginning with 
identifying the capabilities necessary to perform across a full range of military operations 
and ending with the JCIDS document review, validation, and approval process. Between 
those two points, document relationships are addressed including the ICD, CDD, and 
Capabilities Production Document (CPD). 

Throughout the document, simple references are made to implementing and using 
HSI in the JCIDS process; however, the references are vague and generally require a 


preliminary understanding of HSI. 


4. RECOMMENDATIONS FOR LEVEL 1 DOCUMENTS 


At the highest level, regardless of the purpose of the document, the act of 
performing HSI must be established. The three documents listed at the highest level— 
DoDD 5000.1, DoDI 5000.02, and CJCSI 3170.01F— have different purposes; however, 
they all address some aspect of the acquisition process. In order for HSI to trickle down 
through the levels of documentation, the actual act of performing HSI must be 
acknowledged and addressed as a process, rather than just a single mention that HSI shall 
be conducted by the PM. As mentioned in Chapter III, the act of doing HSI is defined as 

. .. the process of conducting Human Systems Integration is intended to 

integrate human related issues into the development of the product by 

identifying specific human-related and mission-related performance and 
system design requirements, communicating those requirements 
throughout the design process, and ensuring those requirements are met 

(VS, Vol. 2, 2005, p. 12). 

This process is essential and must be imbedded at the highest possible level to 
ensure that HSI is performed with continuity throughout the Acquisition Life Cycle. 
Currently, we have identified that this gap exists within both DoDD 5000.1 and 
CJCSI 3170.01F. We recognize that DoDI 5000.02 addresses the mere act of doing HSI; 
however, it does not encompass and address the definition provided above. If kept as is, 
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the definition from DoD 5000.02 must also be included in the other two documents 
named; however, that situation is not ideal. Implementing the new definition of the 
process of doing HSI in all three documents will better lay the foundation for continuity 
among the documents and provide clear guidance for lower-level policy. 

We acknowledge that all three documents at this level establish policy and 
guidance with respect to differing parts of acquisition. However, none of the documents 
attempt to establish policy directly related to HSI, which is why a gap is present in all the 
documents. HSI policy is defined as a planned course of action that is intended to be used 
to set forth guiding principles and procedures for ensuring that HSI is properly embedded 
throughout the entire acquisition strategy to produce the most advantageous products to 
the user at the lowest possible cost. The policies that are currently set forth in the 
documents address HSI as an act rather than a process. By acknowledging HSI as a 
process, policy can easily be established at the highest level to ensure implementation 
through all levels of documentation, as well as all phases of the Acquisition Life Cycle. 

DoDD 5000.1 has a gap in block 1.2, denoted as “participate in the IDAT&L Life 
Cycle Management Framework.” This gap is not present in the other two documents in 
level 1. Based on that fact, it is not necessary to implement change in DoD 5000.1, 
however, a change is recommended. Since the purpose of DoDD 5000.1 is to “provide 
management principles and mandatory policies and procedures for managing all 
acquisition programs,” (DoD, 2003, p. 1 (a)) it is difficult to effectively make that claim 
without addressing participation in the Life Cycle framework. One can make the 
assumption of participation; however, it is not explicitly stated. 

Based on our model, the establishment of an HSI reporting authority is critical for 
oversight of HSI in the acquisition process. The CJCSI 3170.01F outlines several joint 
staff directors who are responsible for individual domains; however, there is no 
integrative structure to look at HSI as a single process, rather than just individual 
domains. In an ideal setting, the HSI reporting authority should be implemented as a 
structure to ensure an open line of communication throughout all organizations in HSI 
and the acquisition framework, from top to bottom, to effectively track and report on all 


HSI-relevant areas and provide oversight for successful program acquisition. This 
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authority should include personnel from specific services as the primary cornerstones of 
the authority, and be supplemented by joint figures when deemed necessary for a specific 
program. The domains need to be addressed as integrated parts of the process to allow 
trade-off to occur, rather than being addressed individually. In order for HSI to be 
effective, the domains cannot exist independently from one other. 

Establishing a single definition for HSI is imperative for allowing this process to 
move forward and be fully integrated into the acquisition process. A definition gap has 
been identified within DoD 5000.1 and DoD 5000.02. A definition is provided for HSI in 
the CJCSI 3170.01F; however, the definition centers on an outdated document (DoD 
5000.2, 2005) and the individual domains that make up HSI. As an alternative, we 
recommend that HSI be explicitly defined in all three documents as an 

. acknowledgement that the human is a critical component of any 
complex system. It is an interdisciplinary approach that makes explicit the 


underlining tradeoffs across the HSI domains, facilitating optimization of 
total system performance. (Miller & Shattuck, 2006, p. 4) 


By implementing this definition at the highest level of documentation, we feel 
confident that it will provide clear guidance for the lower levels. It will also set the 
precedence that this definition must be followed by all levels, therefore establishing 
continuity across all levels. In addition to the definition, the following domains must 
remain as cornerstones of the HSI process: Manpower, Personnel, Training, Safety, 
Occupational Health, Habitability, Survivability, Environment and Human Factors 
Engineering. CJCSI 3170.01F lists the domains without defining them. However, DoDI 
5000.02 defines the domains clearly and provides explicit deliverables. These domains 
and definitions must be updated to reflect the same definition and description of domains 
in each document. Currently, DoDD 5000.1(2003) does not address domains at all. 

Just as establishing a common definition for HSI is essential, so is identifying key 
players throughout the phases of the Life Cycle. Currently, the documentation shows a 
gap in all three documents leveling this area. It is recommended that key players be 
named throughout the Life Cycle including users, stakeholders, engineers, managers, etc. 
to ensure continuity and establish a solid framework for conducting HSI activities 
throughout the process. By identifying key players early and at the highest level of 
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documentation, HSI will not fall by the wayside at various stages of the Life Cycle. In 
addition, these HSI and specific individuals can be held accountable for deliverables 
involving HSI trade-offs. These players must be established in at least one of the three 
documents, if not all three, to clearly identify these individuals and help create an HSI 
reporting structure. 

DoDI 5000.02 clearly defines and details the five phases of the acquisition 
process (MSA, TD, EMD, PD, and Operations and Support (OS)), however, it does not 
fully define the role that HSI plays within those phases. By using the recommendations 
above, clearly defining HSI, establishing HSI policy, and recognizing participation in the 
IDAT&L Life Cycle management framework, it is imperative that these definitions must 
be amended to include the specific attributes and roles that HSI practitioners play. Once 
these definitions are amended, they must be carried through to ensure continuity 
throughout the Life Cycle. Neither DoDD 5000.1 nor CJCSI 3170.01F mention or define 
the phases. Because DoDI 5000.02 is fairly thorough, it meets the minimum requirement 
for the documents at this level. There would be no harm in implementing them in the 
other two documents; however, implementation is not necessary. 

Overall, the level 1 documents fail to meet the mark on many key points, leaving 
many gaps according to the model; however, the changes that are required to lay a solid 
foundation and amend the documents to fill the gaps are reasonable and will provide 


concrete footing for HSI in the acquisition world. 


E. DOCUMENT GAPS AT LEVEL 2 
1. OPNAVINST 5310.23 


The purpose of this instruction is to address HSI throughout the Navy. It was 
established through the Office of the Chief of Naval Operations and is the Navy’s 
overarching documentation on how HSI should be structured in the Navy. As of 
January 2009, this policy has not been officially signed, so it is still considered in draft 
form. Analysis of this documentation identified the following gaps. We have included the 
portions of the model that pertain to each level to allow the reader to visually see where 


the gaps are in each level on the model for this specific document. The boxes that have a 


ay) 


yellow outline are the gaps we have identified. Additionally, the gaps are also listed in 
bullet format. Figure 14 shows the gaps in the policy side of the model for this document. 
Figure 15 shows the gaps in the operational side of the model through TD for this 
document. Figure 16 shows the gaps in the operational side of the model through OS for 


this document. 


° Define HSI and Domains 
e Operational Reporting Authority 
e Administrative Reporting Authority 


e Identify Roles/Key Players in Operational Reporting Authority 


e Identify Roles/Key Players in Administrative Reporting Authority 

e Identify Key Organizations throughout the Life Cycle at the Service Level 
(Operational) 

e Identify Key Organizations throughout the Life Cycle at the Service Level 
(Administrative) 


e Apply Defined HSI Domains 

e Ensure Integration of Domains 

e Identify HSI Key Players throughout the Phases of the Life Cycle 

e Technology Development Phase 

e Transition from Technology Development Phase to Engineering and 
Manufacturing Development Phase 

e Engineering and Manufacturing Development Phase 

e Transition from Engineering and Manufacturing Development Phase to 
Production and Deployment Phase 

e Production and Deployment Phase 


e Operations and Support Phase 
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Figure 14. Gaps Identified in OPNAVINST 5310.23 (Policy Side) 
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Figure 15. Gaps Identified in OPNAVINST 5310.23 (Operational Side through TD) 
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Gaps Identified in OPNAVINST 5310.23 (Operational Side through OS) 


Figure 16. 








61 


Production and 
Deployment (PD) Phase 








: Operational Readiness 
Assessment 


Production Baseline 








: Implement Maintenance 
: Objectives 








Cost and Manpower 
Estimate 














Operations and Support 
Phase 










‘ In-Service Review Data : Disposal Plan 








Cost and Manpower 


HSI Action Plan 
Summary 





Revised Training Systems: 
Plan (for upgrades / next : 
increment) ‘ 





Inputs to CDD (Next 
Increment) 


Operational Readiness : 
Assessment 





: Specifications for System 


Lifecycle Sustainment Modifications / Upgrades 





* Implement Maintenance : 
Objectives 






User Input / Feedback : 


Document lessons 
Learned 








1.2.1.9.1 


2. SECNAVINST 5000.2D 


The main purpose of SECNAVINST 5000.2D is to give the Navy guidance on 
how to merge the JCIDS and the acquisition process. This document includes chapters on 
systems engineering and HSI. After reviewing this instruction, the following items are 
identified as gaps within our model. We have included the portions of the model that 
pertain to each level to allow the reader to visually see where the gaps are in each level 
on the model for this specific document. The boxes that have a yellow outline are the 
gaps we have identified. Additionally, the gaps are also listed in bullet format. Figure 17 
shows the gaps in the policy side of the model for this document. Figure 18 shows the 
gaps in the operational side of the model through TD for this document. Figure 19 shows 


the gaps in the operational side of the model through OS for this document. 


e Define HSI and Domains 
e Operational Reporting Authority 
e Administrative Reporting Authority 


e Identify Roles/Key Player in Operational Reporting Authority 


e Identify Roles/Key Players in Administrative Reporting Authority 

e Identify Key Organizations throughout the Life Cycle at the Service Level 
(Operational) 

e Identify Key Organizations throughout the Life Cycle at the Service Level 
(Administrative) 


e Apply Defined HSI Domains 
e Ensure Integrations of Domains 


e Identify HSI Key Players throughout the Phases of the Life Cycle 


e Transition Criteria from JCIDS to Materiel Solutions Phase 
e Materiel Solutions Analysis Phase 
« Transition Criteria from Materiel Solutions Phase to Technology 


Development Phase 
e Technology Development Phase 
e Transition Criteria from Technology Development Phase to Engineering 


and Manufacturing Development Phase 
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Engineering and Manufacturing Development Phase 

Transition Criteria from Engineering and Manufacturing Development 
Phase to Production and Deployment Phase 

Production and Deployment Phase 


Operations and Support Phase 
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Figure 17. Gaps Identified in SECNAVINST 5000.2D (Policy Side) 


64 





Establish Policy 


«Su! 








Participate in IDAT&L Life} 
Cycle Management 
Framework 


1.2 


Identify HSI Key Players 
Throughout the Phases 


of the Lifecycle 
1.21 








Functional Solutions 
Analysis 





Acknowledgement of 
Materiel Solution 





Initial Capabilities 
Document 











Figure 18. 


Analysis (MSA) 
Phase 
1.212 







Test and Evaluation 
Strategy 





Concepts 


Alternative Concepts 





Initial Capabilities 
Document 


Plan 


Manager 





: System Engineering Plan 


Support and Maintenance: 









Technology Development : 
: Strategy 


Materiel Development 
Decision 





Cost / Manpower 
Estimates 





User Input / Feedback 





Preliminary System 
‘Specification 





121.217 








Proposed Training 
Systems Plan 











echnology 
Development (TD) 
Phase 





Systems Performance 
Specification 


Test and Evaluation 
Master Plan 





System Threat 
Assessment 


2 Technology Readiness = 
Assessment 








Review 





System Support and 
Maintenance Objectives : 








Gaps Identified in SECNAVINST 5000.2D (Operational Side through TD) 


65 


ngineering and 
Manufacturing 
Development (EMD) 


Production and 
Deployment (PD) Phase 


Operations and Support 














Phase 


























































































poccce> eee 
ee eee BoE Gee ADEE NS i aa 
Milestone Exit Criteria ‘Product Support Package: HSI Action Plan : User Input/Feedback : | : In-Service Review Data ° 
g : ‘ ell : : 
| | 
Ws alk. teutscinsne ste coset itvercenet. Meme e Sees eahee tet | | teeeeeeeeeeeceeeeeeel Lesecenvererser ens 
She, Stee | | Sb aebe 
: 4 | : E : a | 
CDD : Information Support Plan : PESHE CPD | Production Baseline ?, Operational Readiness I Cost andi Manpower 
: \ Assessment Summary 
| 
LauRentumudaaebpa lass ) rr Meatuasiacean Ll Gisltia tae eteniaoes tebtels 8 
| 
Approved Tr : Implement M : 
5. pproved Training + i, : Implement Maintenance : | F 
: Name Program Manager : Systems Plan integrated System Design: Product Support Package: ° Objectives Product Support Package 
| 
omens lee a 
1.2.1.5.1 ‘ i Fras a 
ae : te a Inputs to CDD (Next :Revised Training Systems: 
‘Systems Engineering Plan. CDR PESHE + Implement Training Plan : | Increment) : Plan (for upgrades /next : 
: : | : increment) : 
Ducemetnaumeiasonepen aigetievanneieesaas |) |. qq git Eudvasscatsiis | 
susie evencaalee opel sista | oar 
Configuration Items x ll ee 7 ' : 
KPPs Component — Level Cost pene :Systems Engineering Plan: | : New Program Initiation >: Sutin i 
Specification e > if 8 
ae ! 
Pita eanaeasnt-ntp \: paaqepeenrsy are 
been ee — =e 
1.2.1.8.1 : : 
: Initial Product Baseline < User Input / Feedback Lifecycle Sustainment : Meditations Usitedes A 
Operational Test and Test and Evaluation User Input / Feedback : Implement Maintenance : 
Evaluation Report P S Objectives 
Post PDR Assessment « Developmental Test and - Document lessons 
Evaluation Learned 
, - 1.2.1.9.1 
: Post CDR Assessment : 


Figure 19. 











1.2.1.6.1 





66 


Gaps Identified in SECNAVINST 5000.2D (Operational Side through TD) 


3 RECOMMENDATIONS FOR LEVEL 2 DOCUMENTS 


Our model was developed to ensure that all the policy and guidance flows from 
the highest levels of documentation down to the lowest levels. This means policy that 
was stated previously at the highest level, must also be included at the lowest levels. 
Therefore, the reader will note that we state “recommendation referred to at the highest 


level.” By this, we are trying to avoid restating the recommendations previously given. 


Having a single definition and list of HSI domains is imperative for the initial 
steps of unifying the HSI and acquisition process. Without a single, common definition 
throughout all of the DoD and DoN policies, the meaning and purpose of HSI will be 
interpreted differently by each user. There is a gap in both OPNAVINST 5310.23 and 
SECNAVINST 5000.2D, with respect to the definition of HSI and the domains. The 


recommendation to close the gap was referenced above in the Level | documentation. 


Having a reporting authority for both the operational and administrative chain of 
commands is imperative. These are two distinct functions of our military that need to 
have people informed of the HSI process within their offices. We have noted a gap for 
both documents and recommend that someone be appointed as the HSI Operational 
Reporting Authority, along with the HSI Administrative Reporting Authority, to ensure 
that information from all areas of HSI is being reported to the overall HSI Reporting 
Authority. See Figure 20 for visual breakdown. Level | criterion is marked on the model 
in red. Level 2 criteria are marked on the model in green. Level 3 criteria are marked on 


the model in blue. 


67 





4.4.4.1.4.1.1 4.4.4.2.1.1.1 


Figure 20. The Ideal Model (Policy Side) 


Along with a reporting authority designated for the operational and administrative 
chains of command, HSI roles and key players must be identified. Without the 
identification of specific roles and key players, HSI cannot be effectively completed 
within the acquisition process. To ensure the effective completion of HSI throughout the 


entire acquisitions process, we recommend that these roles and key players be identified. 


Having a single HSI definition and list of domains satisfies the requirements for 
the highest level of documentation, but we realize that at the lower levels there must be 
more direction. Currently, there is a gap within both documents at this level. To 
effectively accomplish HSI in the acquisition Life Cycle, the application and integration 
of the definition and domains must be present. For example, if an acquisition program has 
multiple services, a common set of domains and definitions are essential, as each service 


emphasizes different domains, as noted in Chapter I. 
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HSI Key Players throughout the Phases of the Life Cycle recommendations are 
identified in Level 1. 

The recommendations of the different phases can be found in Level 1. 

The OPNAVINST 5310.32 is strictly geared towards the JCIDS process and HSI 
within that process. Therefore, there are gaps that can be found from the lack of direction 
for the Transition Criteria from Materiel Solutions Analysis Phase to Technology 
Development Phase, the Transition Criteria from Technology Development Phase to 
Engineering and Manufacturing Development Phase, and the Transition Criteria from 
Engineering and Manufacturing Development Phase. Each of these transitions must be 
addressed to ensure that HSI is being done throughout the entire Acquisition Life Cycle. 
The SECNAVINST states that “the PM and sponsors shall address HSI throughout all the 
phases of the acquisition process” (DoN, 2008, p. 12 (b)). The simple wording of “shall” 
means that this is required to be addressed, but not necessarily documented. In order to 
optimize the effects of our systems, HSI must and should be addressed and documented 
throughout all of the phases. Wording can seem mundane, but the effects of a single word 
can mean not having to do a portion of what should be required. 

As a whole, the Level 2 documents seemed to be laid out in such a way as to 
properly facilitate the use and management of HSI. However, there are still many gaps 


that can be fixed to optimize the effects HSI can have on a program. 


F. DOCUMENT GAPS AT LEVEL 3 


1. Virtual SYSCOM Human Systems Integration Guide, Volumes 1 and 
2 


This document was established by the Virtual SYSCOM in 2005. Their purpose is 
to unify the practices and methods used within the different SYSCOM to develop and 
integrate HSI to the Life Cycle. We have included the portions of the model that pertain 
to each level to allow the reader to visually see where the gaps are in each level on the 
model for this specific document. The boxes that have a yellow outline are the gaps we 
have identified. Additionally, the gaps are also listed in bullet format. Figure 21 shows 
the gaps in the policy side of the model for this document. Figure 22 shows the gaps in 
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the operational side of the model through TD for this document. Figure 23 shows the 


gaps in the operational side of the model through OS for this document. 
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Operational Readiness Assessment 
Implement Maintenance Objectives (PD) 
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2. NAVSEA HSE Best Practices Guide 


This document was established by NAVSEA in 2009. The purpose is to unify the 
practices and methods used within the NAVSEA to develop and integrate HSI within 
systems engineering and the Life Cycle. We have included the portions of the model that 
pertain to each level to allow the reader to visually see where the gaps are in each level 
on the model for this specific document. The boxes that have a yellow outline are the 
gaps we have identified. Additionally, the gaps are also listed in bullet format. Figure 24 
shows the gaps in the policy side of the model for this document. Figure 25 shows the 
gaps in the operational side of the model through TD for this document. Figure 26 shows 
the gaps in the operational side of the model through OS for this document. 

e Establish Policy 

e Establish HSI Reporting Authority 


e Define HSI and Domains 
e Operational Reporting Authority 
e Administrative Reporting Authority 


e Identify Roles/Key Players in Operational Reporting Authority 

e Identify Roles/Key Players in Administrative Reporting Authority 
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e Product Support Package (OS) 


e Inputs to CDD (Next Increment) 
e New Program Initiation 
e Life Cycle Sustainment 


e Disposal Plan 
e PESHE (OS) 


e Revised Training Systems Plan (for upgrades/next increment) 
e Operational Readiness Assessment (OS) 
e Implement Maintenance Objectives (OS) 
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Figure 24. Gaps Identified in NAVSEA HSE Best Practices Guide (Policy Side) 
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Figure 25. Gaps Identified in NAVSEA HSE Best Practices Guide (Operational Side through TD) 
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Figure 26. Gaps Identified in NAVSEA HSE Best Practices Guide (Operational Side through OS) 
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3. Recommendations for Level 3 Documents 


The Virtual SYSCOM’S Human Systems Integration Guide, Volumes | and 2 and 
NAVSEA’s HSE Best Practices Guide are unique documents in our analysis. They 
cannot be considered true policy for the Navy, but rather are guidance documents that 
were created as a reference for those participating in HSI activities throughout the Navy. 
With this in mind, in some instances, we have recommendations that were not originally 


intended for these documents, due to changes and revisions within the entire HSI process. 


The recommendations for the following were previously stated and in Levels 1 
and 2 recommendations. Establish HSI Reporting Authority, Define HSI and Domains, 
Operational Reporting Authority, Administrative Reporting Authority, Identify 
Roles/Key Players in Operational Reporting Authority, Identify Roles/Key Players in 
Administrative Reporting Authority, and Identify Key Players throughout the Phases of 
the Life Cycle. 


A gap that has been noted within the Virtual SYSCOM HSI Guide, Volumes | and 
2, is the lack of acknowledgement of a materiel solution. This can be attributed to the fact 
that this guide is somewhat outdated and does not contain the changes that have been 
made to the Life Cycle, to include phase changes that are documented in DoDI 5000.02. 
Regardless, there must be an acknowledgment of the materiel solution in order to move 
through the Life Cycle. An HSI practitioner should be involved in this process to ensure 


that HSI is being considered from the start of the program. 


The Preliminary System Specification was not addressed by the HSE Best 
Practices Guide. This step, along with the revisions of the System Specification, which 
will be discussed later, is a very important aspect of the acquisition of a system. 
Everything that is considered in this step, must have an HSI practitioner to oversee the 


parameters that are discussed. 


A T&E strategy is critical from the start of the design of the system. Along with 
the establishment of a T&E strategy, an HSI practitioner should be involved with the 
entire T&E process, including the developmental and operational testing of the program, 


to ensure that all domains are being carefully tested. A gap is present in the HSE Best 


80 


Practices Guide and it is therefore recommended that HSI be fully integrated with the 


development of a T&E strategy early in the Life Cycle. 


A significant gap that we found within our analysis is the PM being the position 
that is in charge of HSI. We have stated throughout our research that it is imperative to 
have HSI throughout the entire acquisition Life Cycle. If the PM is the person in charge 
of overseeing HSI, then there is a gap until the PM is named after Milestone B. This 
means that there is no position that oversees HSI within that program for most of the 
beginning of the acquisition process. Therefore, we recommend that a Materiel Solution 
Manager be named after a materiel solution has been identified. This person will oversee 
HSI until the PM is named and is fully briefed on what has been occurring throughout the 
program up to that point. The Materiel Solution Manager can be seen somewhat as an 
Executive Officer, who will be responsible for the HSI portions until the PM comes 
onboard and is fully briefed. This ensures that there is a “chain of command,” or a 
position of authority, on documentation and any recommendations that need to be made 


with regard to HSI prior to the involvement of the PM. 


To ensure that the user is involved with the acquisition process, we have 
implemented a User Input/Feedback loop into each phase of the Life Cycle. Having the 
input of the user is imperative and would greatly increase the effectiveness of how the 
program is carried out. Therefore, we have identified gaps in both documents where the 
documents do not adequately involve the user for helpful feedback. For each phase that 
has a gap identified, we recommend a formal process of some sort to allow the user to 
give feedback to the key players for the program. There must be an HSI practitioner 
present at these feedback sessions to gain knowledge, suggest information, and handle 


any problems related to HSI. 


Draft KPPs and KPPs are very important to the Acquisition Life Cycle. The 
continuous development of KPPs throughout the different phases is imperative for the 
development and production of the system. HSI practitioners must be involved in the 


development of KPPs from the draft throughout the entire process. 
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The Information Support Plan, Footprint Reduction, System Performance 
Specification, Technology Readiness Assessment, Acquisition Strategy, Integrated 
Baseline Review, and Program Protection Plan are all important parts of the Technology 
Development Phase. Each of these is integral in the successful acquisition of a system 
and must have an HSI practitioner involved to ensure that the program is considering all 
the domains of HSI. The Best Practices Guide does not fully incorporate the importance 
of HSI and these key activities within the acquisition process. As stated previously, “the 
PDR will inform requirement trades; improve cost estimation; and identify remaining 
design, integration, and manufacturing risk” (DoD 5000.02, 2008, p. 19). We 
acknowledge that the documents at this level have not been updated to include the new 
changes that have been made to DoD 5000.02. Yet, we want to make clear that it is 


imperative to have an HSI practitioner involved in the development of the PDR. 


The HSE Best Practices Guide does not fully address the importance of HSI at the 
Milestone Exit Criteria. The criteria allow programs to proceed into the next phase of the 
acquisition process. If the Milestone Exit Criteria are not met, the program will not 
proceed. The HSI trade-offs and domains must be examined during these Milestone 
reviews. Therefore, an HSI practitioner must be involved in the discussions or 


considerations for the next phase. 


The Post-PDR Assessment is an “assessment conducted by the PM and Milestone 
Decision Authority to ensure that the PDR report reflects any requirements trades based 
on the assessment of cost, schedule and performance risk” (DoD, 2008, p. 21). The Post- 
CDR Assessment is an assessment of “design maturity as evidenced by measures such as: 
successful completion of sub-system CDRs; the percentage of hardware and software 
product build-to specifications and drawings completed and under configuration 
management...” (DoD, 2008, p. 21). None of these new additions has been added to any 
of the documents at this level. 

The Integrated System Design ensures that each HSI need and constraint is 
managed throughout the entire Life Cycle. The need for having an HSI practitioner 
involved in the Integrated System Design is obvious. Each document must contain 
information about the program having an Integrated System Design. 
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The CDR, PDR,and post-assessment activities have not been updated in either the 
Virtual SYSCOM HSI Guide or the HSE Best Practices Guide; therefore, we recommend 
that these documents be updated to contain the CDR and to include an HSI practitioner in 


the future. 


To plan and develop a program that will create a successful system, many items 
must be taken into consideration. One item of great importance is a maintenance plan. 
This cannot be developed at the end of the Acquisition Life Cycle, but it must be done in 
the beginning to ensure that maintenance aspects are considered while it is still cost 
effective to do trade-offs. Having the maintenance practitioners involved with the process 
is essential. When the maintenance practitioners are developing their maintenance 
manuals, HSI practitioners must be involved in learning and developing effective 
maintenance techniques and to be able to design a system that will allow for minimal 
maintenance. If HSI is not involved until after the manuals are written, it is too late. 
Although the documents discuss maintenance plans, they do not effectively integrate the 


maintenance practitioners and the HSI practitioners throughout the entire Life Cycle. 


Training plans are just as important as maintenance plans. As stated above, the 
training practitioners and HSI practitioners should work hand-in-hand throughout each 
phase of the Life Cycle to develop training programs and training systems that enhance 
system performance. The documents touch on training, but do not provide enough 
guidance to either training or HSI practioners. In many of the previous acquisition 


programs, HSI lessons learned were rarely documented. 


The Operational Readiness Assessment is another part of the acquisition process 
that must include HSI involvement. As the Operational Readiness Assessment is updated, 
the HSI practitioner should be a participant in determining readiness and making any 


suggestions that would benefit the program. 


Many items must be completed, reviewed, and discussed throughout the 
Engineering and Manufacturing Development Phase. Some of the specific requirements 
during this phase that were not discussed in the HSE Best Practices Guide include: 


Information Support Plan, Initial Product Baseline, Product Support Package, and 
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Configuration Items Component—Level Specification. These are all required for this 
phase; having an HSI practitioner involved will enhance the design and production of 


the system. 


Our model has a reduced HSI requirement for the Production and Deployment 
Phase, but this does not mean that HSI should not be considered throughout this phase. 
The HSE Best Practices Guide must include the continuation of HSI practitioners 
participating in the following gaps: Production Baseline, Product Support Package, 
PESHE, Cost and Manpower Estimate, and Operational Readiness Assessment. These are 


all critical to the continuing development of HSI throughout the entire Life Cycle. 


The Operations and Support Phase, just as the Production and Deployment Phase, 
has often left out HSI practitioners. Many HSI considerations are imperative for the 
successful deployment of a system. The HSE Best Practices Guide contains gaps in 
addressing HSI in the following criteria required for the Operations and Support Phase: 
In-Service Review Data, Cost and Manpower Summary, Product Support Package Inputs 
to CDD (Next Increment), New Program Initiation, Life Cycle Sustainment, Disposal 
Plan, and PESHE. Each of these must be addressed to ensure that HSI is performed 


throughout the entire Life Cycle and to ensure the effectiveness of the system. 


Overall, level 3 was difficult to analyze because of the differences between the 
two documents. The Virtual SYSCOM HSI Guide and the HSE Best Practices Guide are 
very informative with regard to HSI and have established an excellent baseline of 
information for those currently doing HSI. If the gaps that we have identified are 
addressed, each of these documents will enhance our acquisition of systems, with respect 


to HSI. 
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Vv. CONCLUSIONS AND RECOMMENDATIONS 


A. OVERVIEW 


Based on the gaps and recommendations derived from the gap analysis performed 
in Chapter IV, this chapter addresses major areas for immediate change within the Navy 
and proposes alternative solutions to enhance overall HSI continuity and effectiveness 
across the acquisition framework. Recommendations for areas of future study in the field 


of HSI will also be made. 


B. CONCLUSIONS 


The DoD and Level 1 documentation do not appear to possess policies or 
effective procedures to systematically integrate HSI into the materiel acquisition process. 
To date, the DoD and DoN have not established adequate policies or procedures for the 
application, execution, support, and integration of HSI into the acquisition framework 
and Life Cycle. To achieve information exchange and adequate guidance in the field of 


HSI, the Navy relies on piecemeal documentation and expertise within its SYSCOMs. 


These current practices fail to achieve the benefits gained by using an integrated 
and comprehensive approach to ensure that appropriate documentation and guidance are 
set for each level. Consequently, the Navy is failing to optimize total system 


performance, with respect to the human, in the acquisition Life Cycle. 


The effectiveness of the Navy’s HSI Program is driven by the operational 
expertise and acquisition experience at the SYSCOM level. Limited guidance, and 
nonstandardized HSI policies and procedures, force the SYSCOM-level commands to 
rely on the HSI knowledge they have in-house to successfully establish and execute HSI 
efforts. Without standardized HSI policies and procedures, the Navy relies on the 
personnel in HSI billets and roles to establish and execute HSI efforts. This practice 
results in inconsistent application, performance, and support among programs—with 
regard to HSI—as well as creating a large variability between programs within the same 


or similar acquisition categories. 
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The consequences of this variability can be lessened by changing the 
organizational culture and providing adequate guidance throughout the Acquisition Life 
Cycle. By empowering more than just the PM to do HSI, there will be better 
communication and effectiveness of managing HSI-related concerns throughout the 


entire acquisition effort. 


Current HSI policy and practices in the Navy do not involve the system user 
enough in the acquisition and decision-making processes. The user is granted limited 
visibility and feedback opportunities throughout the acquisition process. Currently, there 
are only three places throughout the Life Cycle when the user may have visibility, 
depending on the discretion of the PM. This current system does not allow the user to 
effectively influence system design with regard to human considerations. Rather, it 


clouds the understanding of HSI roles and responsibilities. 


By using the model created for this thesis, the current policies and practices were 
assessed and found to be inadequate. Human-related issues are often not raised, 
documented, tracked by an audit trail, or assessed by HSI specialists. These gaps in 
documentation lead to the breakdown of HSI throughout the IDAT&L Life Cycle 
Management Framework, and make it extremely difficult to review the effectiveness of 


the HSI decision-making process regarding the program’s status. 


The successful implementation of HSI into the acquisition process throughout the 
entire Life Cycle must be founded on the basis of senior DoD and Navy officials. To 
achieve service-wide implementation of HSI, the DoD and Navy must rely on a top-down 
management approach and the buy-in of senior Navy officials in order to institute and 
sustain an effective HSI program that spans the entire acquisition Life Cycle. Without 


this senior level buy-in, the program will falter and miss its goals. 


C. AREAS FOR FURTHER RESEARCH 


During this research, other areas of study were identified that would strengthen 
the practice of HSI. These topics were beyond the scope of study for this research, but are 


presented as potential research topics for consideration. 
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Gap/comparative analysis of the current HSI documentation for all other DoD 


agencies, including other services (Air Force, Army, Marine Corps, etc.) 


Whereas this thesis focused solely on the Navy’s use of HSI, no research has been 
conducted on the gaps that lie within the other DoD agencies’ and services’ 
documentation with regard to HSI in the IDAT&L Life Cycle Management Framework. 
The same model used in this thesis can be used as a baseline for other service policies. 
Recommendations can be made to fill gaps in these HSI documents and policies as well. 
These gap analyses can then be used in a larger comparative analysis to ensure that 
appropriate changes are being made at the highest level, to affect all DoD agencies and 
services. 

Analysis of the trade-space tools used/needed to address and fill the gaps 
identified throughout the IDAT&L Life Cycle Management Framework. 


In order to effectively close the gaps identified in this thesis, an analysis of trade- 
space tools should be done based on the needs of each document. As seen throughout this 
thesis, change must be made on every level and that change must also be able to provide 
a smooth transition between document levels. To effectively accomplish this, trade-space 
tools must be used and/or created. These same tools can then be used to assess the 
effectiveness of HSI. 

Analysis of the effects of current Navy HSI policies and procedures on overall 


system procurement. 


As mentioned earlier, due to current documentation and policy gaps, it is rather 
difficult to trace HSI throughout system procurement. An analysis of the effects of 
current HSI policies and procedure on overall system procurement should be done to 
allow a thorough review to occur once changes have been made to policy regarding HSI. 
This review should allow top-level officials, as well as all personnel involved in the HSI 
process, to track changes and gain insight for areas of future improvement. 


Comparative cost and effectiveness analysis of the Navy’s HSI support sources. 


87 


Further study should be done on the cost effectiveness of alternative approaches 
for sourcing and employing HSI support within the DoD acquisition framework. Future 
research should look at the cost effectiveness of both military and contracted HSI support 
services, as well as all combinations of the above. The end goal is to minimize overall 


cost, while still retaining expert skills in HSI specialists. 
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APPENDIX THE IDEAL MODEL 


This model is the same model shown throughout the thesis. The model is broken 
down into three separate diagrams for viewing purposes only. Figure 27 shows the policy 
side of the model. Figure 28 shows the operational side of the model through TD. Figure 
29 shows the operational side of the model through OS. 
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Figure 27. The Ideal Model (Policy Side) 
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90 
















































































. Engineering and 
ag ih We Manufacturing Transition from EMD to Production and Operations and Support 
: Development (EMD) PD (Milestone C) Deployment (PD) Phase Phase 
(Milestone B) Phase 
1215 1216 1217 1218 1.21.91 
ol © | Ie a | 
Ursccirmtmeaseceet Of nteauaietecetin (aamet eatin de cites fom faspeidee Vi Roetier, tence ca? o) clesatentt tet ee, cacpeeeneeat 
d : ae : 3 1 : ; : H B : \ : 
: aa | : : : : 1 3 
: Milestone Exit Criteria ; HSI Action Plan ‘Product Support Package © Milestone Exit Criteria | HSI Action Plan User Input/ Feedback In-Service Review Data: : Disposal Plan 
: | | 7 ! 
I: | 
\ y | It ! 
| i | aan | ! 
H ! | i | 
. 7 7 iH 
1 I | tt i i ! 
1 cD | | hai Supt Pan PESHE ! cP 11 Pin ae cagrcilioi ! bees HS! Acton Pen 
: jill : i \ 
Fi 
1: 4 1-2 Em a | | 
ie aa ee = ge \ 
1 \ PY 1 
I jill), srstpeteesonesn; Gasisenmcnmeny | Seco es | \ 
ge H 42174 \ 
Name Program Manager : pial Integrated System Design: Product Support Package: miei a Product Support Package PESHE 
: oh Systems Plan : : 1: : Objectives ! ; 
I: : ys | 
\ az 
\. / 
eoerree ere fens sella 
Lee inputs to COD et Revised Training Systems 
Systems Engineering Plan: : COR ! PESHE Implement Training Plan : sie : Plan (for upgrades / next : 
; ! \ increment) 
I I 
I | 
Sees e, 
; | (ie ; 
Configuration Items ! i . . 
KPPs : Component-Level = : bast : Systems Engineering Plan: 1 New Program Intiation aa elton 
Specification ! 
. 
ee / 
\ it 
en s\n : ; 
Initial Product Baseline : : User nput/ Feedback : Lifecycle Sustainment aeelgolkc deli 
: : : Modifications / Upgrades : 
Operational Test and Testand Evaluation: Implement Maintenance : 
Evaluation : Report User Input Feetack Objectives 
Past POR Assessment ee and : si a 
1219.4 
Post CDR Assessment 
1216.1 
Figure 29. The Ideal Model (Operational Side through OS) 
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